有在做維運工作的都知道，很多時候，程式就那麼突然地crash了，
我們最重要的工作是要盡快將服務復原到可用狀態讓一切恢復正常。

第二重要的是什麼呢，
第二重要的是要盡可能保留發生狀況當下的所有軌跡紀錄，以便進一步查找問題發生的原因。

如果是我們部屬上去的程式寫法有問題導致的，那在問題發生的當下，查看log應該就能知道事件的來龍去脈了，
如果是資料庫發生問題，通常程式的log也能找到些蛛絲馬跡。

最怕遇到的還是我們無法觸及更深層的部分，可能是使用的框架的bug? 函示庫的bug? WebSphere的bug? 又或者jvm本身的問題?

為了能更好的找到問題發生的原因，我們會需要產出Java dumps and cores，以便做進一步的分析。
在console中，
左側選單 >　Troubleshooting　> Java dumps and cores

透過這個頁面，有三種紀錄檔可以產出，分別是Heap dump 、 Java core 、 System dump

Heap dump可以產生當下jvm記憶體的使用紀錄
Java core 則是產生程式當下執行class的紀錄
System dump則涵蓋了以上兩者的資訊，因此檔案大小也會最大

在這個頁面透過按鈕可以產出以上三種檔案，而產出的檔案預設是放在這裡：

/opt/IBM/WebSphere/AppServer/profiles/AppSrv01

在程式發生問題時產出Heap dump 、 Java core 或 System dump 是很好的留存紀錄的一個方法
不過也要注意系統空間是否足夠，尤其是你的max heap size有另外調整得很高的時候，
很有可能會產生極為龐大的Heap dump及System dump
若把硬碟塞爆了可能會造成二次傷害，拖延了服務復原的時間。

最後補充一下調整這些dump檔產生位置的方法:

只要在/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin
裡面的setupCmdLine.sh
的開頭增加以下幾行

IBM_JAVACOREDIR=/wasdump
export IBM_JAVACOREDIR

IBM_HEAPDUMPDIR=/wasdump
export IBM_HEAPDUMPDIR

IBM_COREDIR=/wasdump
export IBM_COREDIR

TMPDIR=/wasdump
export TMPDIR

並在存檔後重啟server，之後dump檔的產生位置就會改到/wasdump了(也可自行改成其他目錄)

IBM文件可參考：
https://www.ibm.com/support/pages/websphere-application-server-dump-locations-and-setup